The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: Marc-pi <mdxfr@git.wordpress.org>
Co-authored-by: SaxonF <saxonafletcher@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: -450 B (0%)

Total Size: 1.71 MB

_{compressed-size-action}

I think this highlights a couple things:

• In "list view" there's no way to go into "details" view. When clicking a preview, you go into the editor and going back brings you back to the list view. I think that's what we want.
• That said, when switching to either "table" or "grid" views and clicking on pages, going back passes by the details panel first.

Should we try and "link" to the same "url" we use for "list view" in the other layouts too? I'm guessing that means illuminating the "details" panel entirely but to be honest, it's already very hidden with the current state of the PR. Should we wait for the unification of the details and inspector to advance more first?

The other thing that this highlights is that our "frame" animation is kind of broken. The "right side" of the frame/preview should stay stable when you navigate from the root of the site editor into "pages".

I don't think it needs to block this PR but noting that once merged we'll lose the cross-links from the Pages panel to relevant templates like 404 and search results. Related: #41716

It would be good to have some ideas in mind about how we replicate these in data views. Is it technically feasible to display these templates amongst regular pages? Or would a separate view ('Utility' or similar) within Pages work better?

Be carefull, the usage of 14/15/16' laptop screens size is very frequent
i do fear that having 3 panes (2+1) as shown in the screencast will make it difficult to just manage content editing...
not everyone is using a 40' screen like devs or designers !

How challenging would it be to move the "views" functionality (left sidebar) into its own PR/experiment?

We also need to add an edit button and the ellipsis menu to rows on hover. Edit button opens editor which is identical to clicking frame.

In "list view" there's no way to go into "details" view. (...) Should we try and "link" to the same "url" we use for "list view" in the other layouts too?

Yes, definitely. I was planning to look into that as a follow-up given that it already works that way in trunk, but perhaps it's best to do it in this PR as it changes the main flow — best not to change it too many times.

I don't think it needs to block this PR but noting that once merged we'll lose the cross-links from the Pages

In the previous iteration we had them in the left sidebar, as they are now in trunk. Is that idea still valid? Probably a follow-up if that's ok.

How challenging would it be to move the "views" functionality (left sidebar) into its own PR/experiment?

Can you expand on this?

In the sidebar area, we have the default views (shipped in 6.5 and stable) plus the custom views (the only piece that remains hidden under the "wp-admin" experiment).

We also need to add an edit button and the ellipsis menu to rows on hover.

Yes. I'm landing the whole issue by pieces.

Is that idea still valid? Probably a follow-up if that's ok.

It might be okay as a stop-gap, but I hope we can come up with something better. Fine to handle in a follow-up.

@youknowriad I've fixed the back flow and it works like the existing pages in trunk:

• if there's a postId parameter: it goes back through the details to the index view
• if there is not: it goes back to the index view directly

Trunk

This PR

@oandregal In the last video you just shared, it's really unclear why the behavior is different when you "select item" or not. I feel like they should both do the same and go back to the list view no?

I feel like they should both do the same and go back to the list view no?

I actually understood the opposite in your previous comment: that we should maintain the details view until the new experience that substitutes it is in place.

This works the same it currently does in trunk: when nothing is selected, we don't have information to display the details view (the postId param), so it doesn't go through the details view. It's also the same that happens in the site editor root:

It was also strange for me to see how the back flow goes through details only if there's a previous selection (postId in URL). A potential follow-up is to make the postId parameter always part of the URL: set it upon the site editor's first load. We have that info as part of the edited entity, though I understand we are moving towards having a single source of truth for navigation (the URL), so I'd rather do that. Thoughts?

A potential follow-up is to make the postId parameter always part of the URL: set it upon the site editor's first load. We have that info as part of the edited entity, though I understand we are moving towards having a single source of truth for navigation (the URL), so I'd rather do that. Thoughts?

I don't like that, I think the issue will fix itself when we remove the details step.

In the last video you just shared, it's really unclear why the behavior is different when you "select item" or not. I feel like they should both do the same and go back to the list view no?

I don't fully understand the technical implications but I agree with this. Ideally the W button should take you to list view.

Is the concern that if we take you to list view then the details panel is effectively removed from the experience? For pages that doesn't seem like a huge deal because their detail panels offers very little value. But I suppose it would be a bit problematic for templates like Blog Home, where you can edit settings in the Details panel but not in the Inspector (yet). If we don't want to remove access to those settings then yes this is may be a necessary evil for now.

I don't fully understand the technical implications but I agree with this. Ideally the W button should take you to list view.

This is how the list view works in trunk and how it initially worked in this PR (no details in the back flow).

I changed it to 1) make it similar to how table & grid work, which still use the details and 2) because when I asked around about this flow, people felt it was better to leave the details until the new thing lands (as I understand it, the details has a purpose that hasn't been yet absorbed by any other thing).

If the feeling has changed, I'm happy to get rid of the details entirely, though it's a bit orthogonal to this work.

Going to go ahead with this to unblock further work.